WO 2010/095087 A1 describes a control system for a lighting-control network. The control system comprises a controlled device controlled by a controller having receiving means for receiving command signals, and having a first, second and third storage location for storing a personal ID or address, network ID and the ID of a remote control device, respectively. The control system further comprises at least one user-operable remote control device, designed for transmitting command signals. A command signal comprises a target address code, a network ID code, a sender address code and a command code. Normally, the controller only responds to control signals if target address code, network ID code, and sender address code match with the information in memory. The controller is capable of operating in a “No Network” mode, in which the controller responds to a reset command irrespective of target address code, the network ID code and the sender address code. Luminaires that comprise at least one lighting unit for generating light and a lighting-control processor for controlling operation of the at least one lighting unit have become more and more complex. This is related to an increasing level of intelligent operation enabled by the use of one or more sensors and the use of a microcontroller as the lighting-control processor. The lighting-control processor is typically configured to execute an implemented logic and has exchange means to interface with other devices in a given network, such as an area controller or other luminaires, in particular neighbor luminaires. With an increasing level of intelligence executed by the lighting-control processor, susceptibility for failure also increases.
US 2012/0158161 A1 discloses a single controller platform for controlling and monitoring security, home automation, and monitoring devices. The controller platform further provides for a rules-based response to receiving sensor events, including causing actions to be performed by the controller platform or to cause actions to be performed by sensor devices. An example of a microkernel operating system usable by embodiments is a QNX real-time operating system. Under such a micro-kernel operating system, drivers, applications, protocol stacks and file systems run outside the operating system kernel in a memory-protected user space. Such a microkernel operating system is described to provide fault resilience through features such as critical process monitoring and adaptive partitioning. It is described as a result that components can fail, including low-level drivers, and automatically restart without affecting other components or the kernel and without requiring a reboot of the system, and that a critical process monitoring feature can automatically restart failed components because those components function in the user space.